Enhanced remote key management for an enterprise in a cloud-based environment

ABSTRACT

Systems and methods are disclosed for facilitating remote key management services in a collaborative cloud-based environment. In one embodiment, the remote key management architecture and techniques described herein provide for local key encryption and automatic generation of a reason code associated with content access. The reason code is logged by a hardware security module which is monitored by a remote client device (e.g., an enterprise client) to control a second (remote) layer of key encryption. The remote client device provides client-side control and configurability of the second layer of key encryption.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 14/472,540, filed on Aug. 29, 2014, titled “ENHANCED REMOTE KEYMANAGEMENT FOR AN ENTERPRISE IN A CLOUD-BASED ENVIRONMENT”. The presentapplication is also related to U.S. patent application Ser. No.14/056,899, filed on Oct. 17, 2013, titled “REMOTE KEY MANAGEMENT IN ACLOUD-BASED ENVIRONMENT”, which claims priority to and benefit from U.S.Provisional Patent Application Ser. No. 61/715,208, filed on Oct. 17,2012, titled “ADAPTIVE ARCHITECTURES FOR ENCRYPTION KEY MANAGEMENT IN ACLOUD-BASED ENVIRONMENT”, the content of which is hereby incorporated byreference in their entirety.

BACKGROUND

As electronic and digital content use in enterprise settings and/orother organizational settings has become the preferred mechanism forproject, task, and work flow management, so has the need for streamlinedcollaboration and sharing of digital content and documents. In suchcollaboration environments, multiple users share, access, and otherwiseperform actions or tasks on content and files in shared workspaces. Thisshared access and collaboration requires high availability of the data(e.g., an unfettered ability to download and upload files) as any numberof users may have access to a file at any given time.

The collaboration environments can include features or mechanisms thatadd security mechanisms to the access of content and files in the sharedworkspaces. Unfortunately, these mechanisms do not provide variableclient-level control of the security mechanism and thus a need existsfor a system that overcomes the above problems, as well as one thatprovides additional benefits.

Overall, the examples herein of some prior or related systems and theirassociated limitations are intended to be illustrative and notexclusive. Other limitations of existing or prior systems will becomeapparent to those of skill in the art upon reading the following.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example diagram of a system having a host serverof a cloud service and/or cloud storage accounts with capabilities thatfacilitate remote key management services.

FIG. 2 depicts a diagram of a web-based or online collaboration platformdeployed in an enterprise or other organizational setting for organizingwork items and workspaces, as one example of a hosted cloud serviceand/or cloud storage accounts with capabilities that facilitate remotekey management services.

FIG. 3 depicts an example diagram of a workspace in a cloud-based,online or web-based collaboration environment accessible by multiplecollaborators through various devices authorized to access the workspace.

FIG. 4A and FIG. 4B depict example data flow diagrams illustratingoperation of components in a collaborative cloud-based environment forfacilitating remote key management services responsive to an uploadrequest and an access request, respectively.

FIG. 5 depicts a block diagram illustrating an example of components ina key service engine for facilitating remote key management services ina collaborative cloud-based environment.

FIG. 6 depicts a block diagram illustrating an example of components ina hardware security module (HSM) for facilitating remote key managementservices in a collaborative cloud-based environment.

FIG. 7 depicts a flow diagram illustrating an example process forfacilitating remote key management services in a collaborativecloud-based environment responsive to an upload request.

FIG. 8 depicts a flow diagram illustrating an example process forfacilitating remote key management services in a collaborativecloud-based environment responsive to an access request.

FIG. 9 depicts a diagrammatic representation of a machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

The following description and drawings are illustrative and are not tobe construed as limiting. Numerous specific details are described toprovide a thorough understanding of the disclosure. However, in certaininstances, well-known or conventional details are not described in orderto avoid obscuring the description. References to one or an embodimentin the present disclosure can be, but not necessarily are, references tothe same embodiment; and, such references mean at least one of theembodiments.

Reference in this specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the disclosure. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Moreover, various features aredescribed which may be exhibited by some embodiments and not by others.Similarly, various requirements are described which may be requirementsfor some embodiments but not other embodiments.

The terms used in this specification generally have their ordinarymeanings in the art, within the context of the disclosure, and in thespecific context where each term is used. Certain terms that are used todescribe the disclosure are discussed below, or elsewhere in thespecification, to provide additional guidance to the practitionerregarding the description of the disclosure. For convenience, certainterms may be highlighted, for example using italics and/or quotationmarks. The use of highlighting has no influence on the scope and meaningof a term; the scope and meaning of a term is the same, in the samecontext, whether or not it is highlighted. It will be appreciated thatsame thing can be said in more than one way.

Consequently, alternative language and synonyms may be used for any oneor more of the terms discussed herein, nor is any special significanceto be placed upon whether or not a term is elaborated or discussedherein. Synonyms for certain terms are provided. A recital of one ormore synonyms does not exclude the use of other synonyms. The use ofexamples anywhere in this specification including examples of any termsdiscussed herein is illustrative only, and is not intended to furtherlimit the scope and meaning of the disclosure or of any exemplifiedterm. Likewise, the disclosure is not limited to various embodimentsgiven in this specification.

Without intent to limit the scope of the disclosure, examples ofinstruments, apparatus, methods and their related results according tothe embodiments of the present disclosure are given below. Note thattitles or subtitles may be used in the examples for convenience of areader, which in no way should limit the scope of the disclosure. Unlessotherwise defined, all technical and scientific terms used herein havethe same meaning as commonly understood by one of ordinary skill in theart to which this disclosure pertains. In the case of conflict, thepresent document, including definitions will control.

Collaboration environments can include features or mechanisms thatprovide security through the use of data item (or file) encryption. Thefile encryption features can, for example, include encrypting anencryption key used that is used to encrypt a data or content item(e.g., a file). As discussed above, existing mechanisms that providesecurity through data encryption do not provide for client-side (e.g.,enterprise-side) control and configurability. Furthermore, the existingmechanisms also do not provide for

Embodiments of the present disclosure include systems and methods forfacilitating remote key management services in a collaborativecloud-based environment using a hardware security module (HSM). Morespecifically, the remote key management architecture and techniquesdescribed herein provide for local key encryption and automaticgeneration of audit log information. The audit information can include areason code and/or metadata associated with content access. The reasoncode enumerates a user behavior performed on the data item in thecollaborative cloud-based environment. The audit information is includedin a secure key request to the HSM which logs the audit information formonitoring by an enterprise client.

At least some of the audit information is logged by the HSM andmonitored by an enterprise (or remote) client to control a second(remote) layer of key encryption at the HSM. More specifically, theenterprise clients monitor access to keys stored at on HSM and can limitor kill access at any time if access inconsistencies are detected.

The HSM can be security hosted in a number of ways. For example, the HSMcan be hosted by the cloud-based platform. In such cases, the HSM islogically separate from other components of the cloud-based platform butaccessible to the components via key requests at the behest of a remoteenterprise client. Alternatively or additionally, the HSM can be hostedby another distinct cloud-based platform such as, for example, AmazonAWS or by a managed services provider (MSP) such as, for example,Equinox Managed Services.

Additionally, in some embodiments, the enterprise (or remote) client canprovide client-side control and configurability of the second layer ofkey encryption. In such cases, a key management engine and/or the HSMcan provide the client-side control and configurability through the useof a rule engine that can process a generated access reason to determinewhether or not to encrypt or decrypt (or request encryption ordecryption of) a corresponding encryption key based, at least in part,on a set of pre-defined client-configurable rules. Additionally, invarious embodiments a kill switch is provided to the client at the HSMand/or the key management engine for facilitating remote killcapabilities.

FIG. 1 illustrates an example diagram of a system having a host server100 of a cloud service and/or cloud storage accounts with capabilitiesthat facilitate remote key management services.

The client devices 102 can be any system and/or device, and/or anycombination of devices/systems that is able to establish a connection,including wired, wireless, cellular connections with another device, aserver and/or other systems such as host server 100 and/or notificationserver 150. Client devices 102 will typically include a display and/orother output functionalities to present information and data exchangedbetween among the devices 102 and/or the host server 100 and/ornotification server 150.

For example, the client devices 102 can include mobile, hand held orportable devices or non-portable devices and can be any of, but notlimited to, a server desktop, a desktop computer, a computer cluster, orportable devices including, a notebook, a laptop computer, a handheldcomputer, a palmtop computer, a mobile phone, a cell phone, a smartphone, a PDA, a Blackberry device, a Treo, a handheld tablet (e.g. aniPad, a Galaxy, Xoom Tablet, etc.), a tablet PC, a thin-client, a handheld console, a hand held gaming device or console, an iPhone, and/orany other portable, mobile, hand held devices, etc. running on anyplatform or any operating system (e.g., Mac-based OS (OS X, iOS, etc.),Windows-based OS (Windows Mobile, Windows 7, etc.), Android, BlackberryOS, Embedded Linux platforms, Palm OS, Symbian platform. In oneembodiment, the client devices 102, host server 100, and app server 110are coupled via a network 106. In some embodiments, the devices 102 andhost server 100 may be directly connected to one another.

The input mechanism on client devices 102 can include touch screenkeypad (including single touch, multi-touch, gesture sensing in 2D or3D, etc.), a physical keypad, a mouse, a pointer, a track pad, motiondetector (e.g., including 1-axis, 2-axis, 3-axis accelerometer, etc.), alight sensor, capacitance sensor, resistance sensor, temperature sensor,proximity sensor, a piezoelectric device, device orientation detector(e.g., electronic compass, tilt sensor, rotation sensor, gyroscope,accelerometer), or a combination or variation of the above.

Signals received or detected indicating user activity at client devices102 through one or more of the above input mechanism, or others, can beused in the disclosed technology by various users or collaborators(e.g., collaborators 108) for accessing, through network 106, aweb-based collaboration environment or online collaboration platform(e.g., hosted by the host server 100).

The collaboration platform or environment hosts workspaces with workitems that one or more users can access (e.g., view, edit, update,revise, comment, download, preview, tag, or otherwise manipulate, etc.).A work item can generally include any type of digital or electroniccontent that can be viewed or accessed via an electronic device (e.g.,device 102). The digital content can include .pdf files, .doc, slides(e.g., Powerpoint slides), images, audio files, multimedia content, webpages, blogs, etc. A workspace can generally refer to any grouping of aset of digital content in the collaboration platform. The grouping canbe created, identified, or specified by a user or through other means.This user may be a creator user or administrative user, for example.

In general, a workspace can be associated with a set of users orcollaborators (e.g., collaborators 108) which have access to the contentincluded therein. The levels of access (e.g., based on permissions orrules) of each user or collaborator to access the content in a givenworkspace may be the same or may vary among the users. Each user mayhave their own set of access rights to every piece of content in theworkspace, or each user may be different access rights to differentpieces of content. Access rights may be specified by a user associatedwith a work space and/or a user who created/uploaded a particular pieceof content to the workspace, or any other designated user orcollaborator.

In general, the collaboration platform allows multiple users orcollaborators to access or collaborate efforts on work items such eachuser can see, remotely, edits, revisions, comments, or annotations beingmade to specific work items through their own user devices. For example,a user can upload a document to a work space for other users to access(e.g., for viewing, editing, commenting, signing-off, or otherwisemanipulating). The user can login to the online platform and upload thedocument (or any other type of work item) to an existing work space orto a new work space. The document can be shared with existing users orcollaborators in a work space.

A diagrammatic illustration of the online collaboration environment andthe relationships between workspaces and users/collaborators areillustrated with further reference to the example of FIG. 2. Adiagrammatic illustration of a workspace having multiple work items withwhich collaborators can access through multiple devices is illustratedwith further reference to the example of FIG. 3.

In one embodiment, client devices 102 communicate with the host server100 and/or people search engine 150 over network 106. In general,network 106, over which the client devices 102, the host server 100,and/or people search engine 150 communicate, may be a cellular network,a telephonic network, an open network, such as the Internet, or aprivate network, such as an intranet and/or the extranet, or anycombination thereof. For example, the Internet can provide filetransfer, remote log in, email, news, RSS, cloud-based services, instantmessaging, visual voicemail, push mail, VoIP, and other services throughany known or convenient protocol, such as, but is not limited to theTCP/IP protocol, Open System Interconnections (OSI), FTP, UPnP, iSCSI,NSF, ISDN, PDH, RS-232, SDH, SONET, etc.

The network 106 can be any collection of distinct networks operatingwholly or partially in conjunction to provide connectivity to the clientdevices 102 and the host server 100 and may appear as one or morenetworks to the serviced systems and devices. In one embodiment,communications to and from the client devices 102 can be achieved by, anopen network, such as the Internet, or a private network, such as anintranet and/or the extranet. In one embodiment, communications can beachieved by a secure communications protocol, such as secure socketslayer (SSL), or transport layer security (TLS).

In addition, communications can be achieved via one or more networks,such as, but are not limited to, one or more of WiMax, a Local AreaNetwork (LAN), Wireless Local Area Network (WLAN), a Personal areanetwork (PAN), a Campus area network (CAN), a Metropolitan area network(MAN), a Wide area network (WAN), a Wireless wide area network (WWAN),enabled with technologies such as, by way of example, Global System forMobile Communications (GSM), Personal Communications Service (PCS),Digital Advanced Mobile Phone Service (D-Amps), Bluetooth, Wi-Fi, FixedWireless Data, 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, 3G LTE, 3GPP LTE,LTE Advanced, mobile WiMax, WiMax 2, WirelessMAN-Advanced networks,enhanced data rates for GSM evolution (EDGE), General packet radioservice (GPRS), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA,UMTS-TDD, 1×RTT, EV-DO, messaging protocols such as, TCP/IP, SMS, MMS,extensible messaging and presence protocol (XMPP), real time messagingprotocol (RTMP), instant messaging and presence protocol (IMPP), instantmessaging, USSD, IRC, or any other wireless data networks or messagingprotocols.

In one embodiment, actions performed on work items or other activitiesthat occur in a workspace can be detected in real time or in near realtime. The host server can generate notifications or notification eventsfor one or more of the plurality of activities and select one or morerecipients for each notification. Various mechanisms or externalmessaging applications can then be used to notify users orcollaborators, including through the web interface to access thecollaboration platform, via email, and/or SMS, for example.

FIG. 2 depicts a diagram of a web-based or online collaboration platformdeployed in an enterprise or other organizational setting 250 fororganizing work items 215, 235, 255 and workspaces 205, 225, 245, as oneexample of a hosted cloud file sharing, collaboration service and/orcloud storage service with capabilities that facilitate remote keymanagement services.

The web-based platform for collaborating on projects or jointly workingon documents can be used by individual users and shared amongcollaborators. In addition, the collaboration platform can be deployedin an organized setting including but not limited to, a company (e.g.,an enterprise setting), a department in a company, an academicinstitution, a department in an academic institution, a class or coursesetting, or any other types of organizations or organized setting.

When deployed in an organizational setting, multiple workspaces (e.g.,workspace A-N) may be created to support different projects or a varietyof work flows. Each workspace may have its own associate work items. Forexample, work space A 205 may be associated with work items 215, workspace B 225 may be associated with work items 235, and work space N maybe associated with work items 255. The work items 215, 235, and 255 maybe unique to each work space but need not be. For example, a particularword document may be associated with only one work space (e.g., workspace A 205) or it may be associated with multiple work spaces (e.g.,Work space A 205 and work space B 225, etc.).

In general, each work space has a set of users or collaboratorsassociated with it. For example, work space A 205 is associated withmultiple users or collaborators 206. In some instances, work spacesdeployed in an enterprise may be department specific. For example, workspace B may be associated with department 210 and some users shown asexample user A 208 and workspace N 245 may be associated withdepartments 212 and 216 and users shown as example user B 214.

Each user associated with a work space may generally access the workitems associated with the work space. The level of access may depend onpermissions associated with the specific work space, and/or with aspecific work item. Permissions may be set for the work space or setindividually on a per work item basis. For example, the creator of awork space (e.g., one of user A 208 who creates work space B) may setone permission setting applicable to all work items 235 for otherassociated users and/or users associated with the affiliate department210, for example. Creator user A 208 may also set different permissionsettings for each work item, which may be the same for different users,or varying for different users.

In each work space A, B, . . . , N, when an action is performed on awork item by a given user or any other activity is detected in the workspace, other users in the same work space may be notified (e.g., in realtime or in near real time, or not in real time). Activities whichtrigger real time notifications can include, by way of example but notlimitation, adding, deleting, or modifying collaborators in the workspace, uploading, downloading, adding, deleting a work item in the workspace, creating a discussion topic in the work space.

Specifically, items or content (content items) downloaded or edited inaccordance with the techniques described in the present disclosure cancause notifications to be generated. Such notifications can be sent torelevant users to notify them of actions surrounding a download, anedit, a change, a modification, a new file, a conflicting version, anupload of an edited or modified file.

In one embodiment, in a user interface of the web-based collaborationplatform where notifications are presented, users can, via the userinterface, create action items (e.g., tasks) and delegate the actionitems to other users including collaborators pertaining to a work item215, for example. The collaborators 206 may be in the same workspace A205 or the user may include a newly invited collaborator. Similarly, inthe same user interface where discussion topics can be created in a workspace (e.g., work space A, B or N, etc.), actionable events on workitems can be created and/or delegated/assigned to other users such ascollaborators of a given work space 206 or other users. Through the sameuser interface, task status and updates from multiple users orcollaborators can be indicated and reflected. In some instances, theusers can perform the tasks (e.g., review or approve or reject, etc.)via the same user interface.

FIG. 3 depicts an example diagram of a workspace 302 in an online orweb-based collaboration environment accessible by multiple collaborators322 through various devices authorized to access the work space.

Each of users 316, 318, and 320 may individually use multiple differentdevices to access and/or manipulate work items 324 (e.g., content items)in the work space 302 with which they are associated with. For exampleusers 316, 318, 320 may be collaborators on a project to which workitems 324 are relevant. Since the work items 324 are hosted by thecollaboration environment (e.g., a cloud-based environment), each usermay access the work items 324 anytime, and from any physical locationusing any device (e.g., including devices they own or anyshared/public/loaner device).

Work items to be edited or viewed may be accessed from the workspace 302in accordance with the platform and/or application independentmechanisms. Users may also be notified of access, edit, modification,and/or upload related-actions performed on work items 324 by other usersor any other types of activities detected in the work space 302. Forexample, if user 316 modifies a document, one or both of the othercollaborators 318 and 320 can be notified of the modification in realtime, or near real-time, or not in real time. The notifications can besent through any of all of the devices associated with a given user, invarious formats including, one or more of, email, SMS, or via a pop-upwindow in a user interface in which the user uses to access thecollaboration platform. In the event of multiple notifications, eachnotification may be depicted preferentially (e.g., ordering in the userinterface) based on user preferences and/or relevance to the user (e.g.,implicit or explicit).

For example, a notification of a download, access, read, write, edit, orupload related activities may be presented in a feed stream among othernotifications through a user interface on the user device according torelevancy to the user determined based on current or recent activity ofthe user in the web-based collaboration environment.

In one embodiment, a notification feed stream includes updates when aninvited user accepts an invitation and/or successfully creates a newaccount through receipt of an invitation from an existing user. Theinvited user, upon creation of the new account, receives the accounthaving enhanced features. The new user can automatically be connected tothe existing user who sent the invitation. The system can alsoautomatically prompt both users to query they wish to be collaboratorsin a common work space.

Work items hosted by a collaboration environment (e.g., a cloud-basedcollaboration environment) can be accessed by users (e.g., users 316,318, and 320) via multiple different devices (e.g., devices 304-314) forviewing, editing, processing or performing other manipulations on workitems. The devices can include applications for accessing a serverhosting a cloud-based platform or service or other backend web services(hereinafter “cloud-based collaboration platform application”) andapplications for viewing, editing, processing, or performing othermanipulations on work items. The communication between such applicationsare generally facilitated by a communication mechanism of the OS. Forexample, in Android OS, the communication mechanism is based on“Intents”. As previously described, the underlying communicationmechanism are generally insecure, and any data passed betweenapplications are visible to all other application on a device.

FIGS. 4A and 4B depict example data flow diagrams illustrating operationof components in a collaborative cloud-based environment 400 forfacilitating remote key management services responsive to an uploadrequest and an access request, respectively, according an embodiment.More specifically, the examples of FIGS. 4A and 4B illustrate acloud-based platform configured to provide an enterprise client withremote key management services allowing the enterprise client to havedirect control and monitoring capabilities over upload and/or access todata items (e.g., data files in the cloud-based platform).

As shown in the examples of FIGS. 4A and 4B, the cloud-based platformincludes a content interface 412, a content encryption/decryption engine414, a key service engine 416, an HSM interface (I/F) engine 418, and adata store 415. The second cloud-based (or 3rd party) platform includesan HSM 420. The enterprise client includes a log monitoring engine 430.Additional or few components/modules/engines are possible at thecloud-based platform, the second cloud-based (or 3rd party) platformand/or the enterprise client.

Referring first to FIG. 4A, which illustrates operation of components ina collaborative cloud-based environment 400 for facilitating remote keymanagement services responsive to an upload request, the cloud-basedplatform first receives a content request 401 at the content interface412. The content interface 412 processes the content request 401 todetermine that the request comprises a request to upload a data item402. The content interface then passes data item 402 or an indicationthereof to the content encryption/decryption engine 414. The contentencryption/decryption engine 414 selects an encryption key 404 andencrypts the data item according to any of a variety of encryptionmethodologies using the selected encryption key 404 resulting in anencrypted data item 403.

The content encryption/decryption engine 414 then passes the encryptionkey to the key service engine 416. The encryption/decryption engine 414can also pass the encrypted data item 403 to the data store 415.Alternatively or additionally, the encrypted data item 403 (or a handlethereto or indicator thereof) can be passed to the key service engine416. The key service engine 416 can use the encrypted data item 403 (orhandle or indicator thereof) to associate one or more key encryptionkeys with the encrypted data item 403. The one or more key encryptionkeys can be later associated with and/or otherwise stored with theencrypted data 403 in the data store 415.

Continuing with the example of FIG. 4A, the key service engine 416selects a local key encryption key (KEK) and uses the local KEK toencrypt the encryption key 404 resulting in an encrypted encryption key.The local KEK may be, for example, selected randomly. The local KEK usedto perform the encryption is noted and maintained by the system forlater decryption purposes, if necessary.

The key service engine 416 also processes the content (upload) request401 to identify audit log information such as, for example, metadata anda reason for the content request. The key service engine 416 alsogenerates a code associated with the reason. By way of example and notlimitation, the metadata can include: an Internet Protocol (IP) addressinitiating the request, a user identifier (ID) associated with therequest, a file identifier (ID) associated with the request, etc. Othermetadata is also possible. By way of example and not limitation, reasonscan include: to fulfill an upload data item request, to fulfill adownload or access data item request, to fulfill a maintenance request,to perform another action (e.g., to perform a text extraction request),to fulfill backend services (e.g., conversion), etc. Other reasons arealso possible and, as discussed, each reason can be coded with reasoncode.

The key service engine 416 next generates a remote key request 405 andsends the request to the HSM I/F engine 418. The HSM I/F engine 418initiates a secure key request 406 which includes at least some of theaudit log information. As shown in the example of FIG. 4A, the securekey request 406 includes the encrypted encryption key, the generatedreason code, and/or identified or generated metadata associated with thecontent request 401. The secure key request directs the HSM 420 to storethe audit log information and sign the audit log information with asecure key. In various embodiments, the audit log information can beincluded in a free form block of the secure key request 406 to the HSM420.

In various embodiments, the key service engine 416 and/or the HSM 420can include a configurable rules processing engine that processes reasoncodes and/or identified or generated metadata associated with thecontent requests to determine whether to accept or reject the requestbased on one or more pre-configured rules. For example, thepre-configured rules can be generated to reject requests with particularreason codes, reject requests from particular IP addresses, rejectparticular users based on user ID, etc. The contents of an example keyservice engine 416 are shown and discussed in greater detail withreference to FIG. 5.

When the HSM 420 receives the secure key request 406, the HSM 420selects a remote KEK and uses the remote KEK to encrypt the encryptedencryption key resulting in a twice encrypted key 408. The HSM 420 canthen respond to the secure key request 406 with a secure key response407. As illustrated, the secure key response 407 can include the twiceencrypted key and the remote KEK. Alternatively or additionally, theremote KEK and/or the twice encrypted key can be stored the HSM 420. Thecontents of an example HSM 420 are shown and discussed in greater detailwith reference to FIG. 6.

The HSM I/F engine 418 receives the secure key response 407 from the HSM420, parses the response to glean relevant information and passes aremote key response 408 to the key service engine 416.

The key service engine 416 subsequently directs the data store to storethe twice encrypted key 408, the remote KEK, and the local KEK in datastore 415. The twice encrypted key 408, the remote KEK, and the localKEK can be stored and/or otherwise associated with the correspondingencrypted data item 403 in the data store 415. Alternatively, if theremote KEK and/or twice encrypted key are stored remotely, information(e.g., IDs) with respect to the KEK and/or twice encrypted key may beassociated with and/or stored with encrypted data item 403.

Referring next to FIG. 4B, which depicts another example data flowdiagram illustrating operation of components in a collaborativecloud-based environment 400 for facilitating remote key managementservices responsive to an access request. The cloud-based platform firstreceives a content request 431 at the content interface 412. The contentinterface 412 processes the content request 431 to determine that therequest comprises a request to access (e.g., download) a data item 445and passes access request 433 on to the key service engine 416.

The key service engine 416 first determines whether the requested dataitem 445 is associated with remote key management functionality. Forexample, each data item can be associated with an enterprise and the keyservice engine 416 can identify the enterprise associated with the dataitem and determine if the enterprise has key management functionality.Alternatively or additionally, an enterprise or client can handle and/orotherwise manage keys on a case-by-case (or item-by-item) basis. In theexample of FIG. 4B, the key service engine 416 determines that therequested data item 445 is associated with remote key managementfunctionality.

The key service engine 416 then determines and/or otherwise identifiesinformation associated with data item 445 and accesses and/or otherwisereceives or retrieves the information from the data store 415. In theexample of FIG. 4B, the information associated with the data item 445includes a twice encrypted key 435, a remote KEK and a local KEK. Asdiscussed above, in some embodiments, the remote KEK and/or the twiceencrypted key may be stored remotely. The key service engine 416 nextprocesses the content (access) request 431 to identify audit loginformation such as, for example, metadata and a reason for the contentrequest. A code is generated that is associated with the reason. The keyservice engine 416 then generates a remote key request 435 including theaudit log information (e.g., the twice encrypted key, the reason code,the metadata, and/or the remote KEK) and sends the request to the HSMI/F engine 418. The contents of an example key service engine 416 areshown and discussed in greater detail with reference to FIG. 5.

The HSM I/F engine 418 initiates a secure key request 437 which includesat least some of the audit log information. As shown in the example ofFIG. 4B, the secure key request 437 includes the twice encryptedencryption key, the generated reason code, the remote KEK, and/oridentified or generated metadata associated with the content request431. The secure key request directs the HSM 420 to store the audit loginformation and sign the audit log information with a secure key. Invarious embodiments, the audit log information can be included in a freeform block of the secure key request 437 to the HSM 420.

As discussed above, the key service engine 416 and/or the HSM 420 caninclude a configurable rules processing engine that processes the remotekey request including the twice encrypted encryption key, the generatedreason code, identified or generated metadata associated with thecontent request, and/or the remote KEK. The remote key service engine420 processes the reason code and/or the metadata to determine whetherto accept or reject the request based on one or more pre-configuredrules. As discussed above, rules can be generated to reject requestswith particular reason codes, reject requests from particular IPaddresses, reject particular users based on user ID, etc. The contentsof an example key service engine 416 are shown and discussed in greaterdetail with reference to FIG. 5.

When the HSM 420 receives the secure key request 437, the HSM 420decrypts the twice encrypted key using the remote KEK and provides theonce encrypted key 439 back to the HSM I/F Engine 418 which parses theresponse and passes a remote key response 440 on to the key serviceengine 416. The key service engine 416 receives the once encrypted keyand decrypts the once encrypted key using the local KEK resulting in theencryption key 441. The key service engine 416 then provides theencryption key 441 to the content encryption/decryption engine 414 todecrypt the encrypted data item 443 resulting in the data item 445. Thecontent encryption/decryption engine 414 provides the data item 445 tothe content interface 412 which, in turn, responds to the contentrequest 431 with the data item 445. As discussed, the contents of anexample HSM 420 are shown and discussed in greater detail with referenceto FIG. 6.

FIG. 5 depicts a block diagram illustrating an example of components ina key service engine 500 for facilitating remote key management servicesin a collaborative cloud-based environment. The key service engine 500can be the key service engine 416 of FIGS. 4A and 4B, althoughalternative configurations are possible.

The key service engine 500 can be part of a web-based or onlinecollaboration environment which can generally be a cloud-based service.The key service engine 500 can include, for example, a request interface505, a key service proxy 510, a key encryption/decryption engine 515, areason generation engine 520, a metadata engine 525, a ruleconfiguration engine 535, a rule processing engine 540, and an HSMinterface 530. Additional or fewer components/modules/engines can beincluded in the key service engine 500 and/or each illustratedcomponent. Further, although illustrated as included as part of the keyservice engine 500, the components/modules/engines can be physicallyand/or functionally distributed.

The request interface 505 can be configured to communicate with othercomponents of the cloud-based platform. Similarly, the enterprise clientinterface 530 can be configured to communicate with components of aremote client device (e.g., enterprise client computers or devices).

The request interface 505 and/or the enterprise client interface 530 canbe networking modules that enables key service engine 500 to mediatedata in a network with entities that are external to key service engine500, through any known and/or convenient communications protocolsupported by the host and the external entity. For example, the requestinterface 505 and/or the enterprise client interface 530 can be anetwork interface that can include one or more of a network adaptorcard, a wireless network interface card (e.g., SMS interface, WiFiinterface, interfaces for various generations of mobile communicationstandards including but not limited to 1G, 2G, 3G, 3.5G, 4G, LTE,etc.,), Bluetooth, a router, an access point, a wireless router, aswitch, a multilayer switch, a protocol converter, a gateway, a bridge,bridge router, a hub, a digital media receiver, and/or a repeater.

As used herein, a “module,” “a manager,” a “handler,” a “detector,” an“interface,” or an “engine” includes a general purpose, dedicated orshared processor and, typically, firmware or software modules that areexecuted by the processor. Depending upon implementation-specific orother considerations, the module, manager, hander, or engine can becentralized or its functionality distributed. The module, manager,hander, or engine can include general or special purpose hardware,firmware, or software embodied in a computer-readable (storage) mediumfor execution by the processor. As used herein, a computer-readablemedium or computer-readable storage medium is intended to include allmediums that are statutory (e.g., in the United States, under 35 U.S.C.101), and to specifically exclude all mediums that are non-statutory innature to the extent that the exclusion is necessary for a claim thatincludes the computer-readable (storage) medium to be valid. Knownstatutory computer-readable mediums include hardware (e.g., registers,random access memory (RAM), non-volatile (NV) storage, to name a few),but may or may not be limited to hardware.

One embodiment of the key service engine 500 includes the key serviceproxy 510 which can comprise any device configured to initiate a remotekey request responsive to a determination that a data item indicated bya content request is associated with remote key managementfunctionality.

One embodiment of the key service engine 500 includes the keyencryption/decryption engine 515 which can provide a first layer ofencryption and decryption for an encryption key. During upload requests,as described in FIG. 4A, the key encryption/decryption engine 515encrypts an encryption key that is selected and used to encrypt thereceived data item. For example, the key encryption/decryption engine515 can select a key encryption key to encrypt the encryption key. Inone embodiment, the key encryption key is selected randomly, however,the key encryption key may be selected in other manners. Once encryptionof the key is complete, the key service engine 500 can store the keyencryption key (KEK) in a data store. In one or more embodiments, theKEKs transferred by the components described herein may be keyencryption key identifiers (IDs).

During access (or download) requests, as described in FIG. 4B, the keyencryption/decryption engine 515 can access a key encryption key from adata store (or memory) and use the key encryption key to decrypt a onceencrypted key received responsive to a remote key request to decrypt atwice encrypted key.

One embodiment of the key service engine 500 includes the reasongeneration engine 520 which can process the content request to identifythe reason associated with the content request and responsively generatethe corresponding reason code. As discussed above, the reason codeenumerates a user behavior performed on the data item in thecollaborative cloud-based environment. The audit information is includedin a secure key request to the HSM which logs the audit information formonitoring by an enterprise client.

One embodiment of the key service engine 500 includes the metadataengine 525 which can process the received content request to identifymetadata associated with the content request. In one embodiment, theremote key request can include the metadata.

One embodiment of the key service engine 500 includes an optional ruleconfiguration engine 530 which can facilitate client configuration ofrules. For example, rules can be generated to reject requests withparticular reason codes, reject requests from particular IP addresses,reject particular users based on user ID, etc.

One embodiment of the key service engine 500 includes an optional ruleprocessing engine 535 which can process requests including the encryptedencryption key, the generated reason code, and/or identified orgenerated metadata associated with the content request and processes thereason code and/or the metadata to determines whether to accept orreject the request based on one or more pre-configured rules. Forexample, rules can be generated to reject requests with particularreason codes, reject requests from particular IP addresses, rejectparticular users based on user ID, etc.

One embodiment of the key service engine 500 includes the HSM interface530 which generates the secure requests that direct the HSM, e.g., HSM420 of FIG. 4, to store the audit log information and sign the audit loginformation with a secure key. As discussed, in various embodiments, theaudit log information can be included in a free form block of the securekey request to the HSM.

FIG. 6 depicts a block diagram illustrating an example of components inan HSM 600 for facilitating remote key management services in acollaborative cloud-based environment. The HSM 600 can be the HSM 420 ofFIGS. 4A and 4B, although alternative configurations are possible.

The HSM 600 can be any physical computing device that safeguards andmanages keys. In various embodiments, the HSM 600 can comprise a plug-incard or an external device that attaches directly to a computer ornetwork server. The HSM 600 can be security hosted in a number of ways.For example, the HSM 600 can be hosted by the primary cloud-basedplatform (i.e., the cloud-based platform on which the key service engineresides). In such cases, the HSM 600 is logically separate from othercomponents of the cloud-based platform but accessible to the componentsvia key requests at the behest of a remote enterprise client.Alternatively or additionally, the HSM 600 can be hosted by anotherdistinct cloud-based platform such as, for example, Amazon AWS or by amanaged services provider (MSP) such as, for example, Equinox ManagedServices.

In various embodiments, the HSM 600 can be part of a web-based or onlinecollaboration environment which can generally be a cloud-based service.The HSM 600 can include, for example, a key service interface 605, a keyencryption/decryption engine 610, kill circuitry 615, a key store 620,an audit log 625, and a client configuration interface 630. Additionalor fewer components/modules/engines can be included in the HSM 600and/or each illustrated component. Moreover, although illustrated asincluded as part of the HSM 600, the components/modules/engines can bephysically and/or functionally distributed.

The key service interface 605 can be configured to communicate withcomponents of the cloud-based platform such as, for example, the keyservice engine 500 of FIG. 5. Similarly, the enterprise monitorinterface 630 can be configured to allow clients (e.g., enterpriseclient computers or devices) to monitor audit logs.

The key service interface 605 and/or the enterprise monitor interface630 can be networking modules that enables the HSM 600 to mediate datain a network with entities that are external to HSM 600, through anyknown and/or convenient communications protocol supported by the hostand the external entity. For example, the key service interface 605and/or the enterprise monitor interface 630 can be a network interfacethat can include one or more of a network adaptor card, a wirelessnetwork interface card (e.g., SMS interface, WiFi interface, interfacesfor various generations of mobile communication standards including butnot limited to 1G, 2G, 3G, 3.5G, 4G, LTE, etc.,), Bluetooth, a router,an access point, a wireless router, a switch, a multilayer switch, aprotocol converter, a gateway, a bridge, bridge router, a hub, a digitalmedia receiver, and/or a repeater.

As used herein, a “module,” “a manager,” a “handler,” a “detector,” an“interface,” or an “engine” includes a general purpose, dedicated orshared processor and, typically, firmware or software modules that areexecuted by the processor. Depending upon implementation-specific orother considerations, the module, manager, hander, or engine can becentralized or its functionality distributed. The module, manager,hander, or engine can include general or special purpose hardware,firmware, or software embodied in a computer-readable (storage) mediumfor execution by the processor. As used herein, a computer-readablemedium or computer-readable storage medium is intended to include allmediums that are statutory (e.g., in the United States, under 35 U.S.C.101), and to specifically exclude all mediums that are non-statutory innature to the extent that the exclusion is necessary for a claim thatincludes the computer-readable (storage) medium to be valid. Knownstatutory computer-readable mediums include hardware (e.g., registers,random access memory (RAM), non-volatile (NV) storage, to name a few),but may or may not be limited to hardware.

One embodiment of the HSM 600 includes the key encryption/decryptionengine 610 which can provide a second layer of encryption and decryptionfor an encryption key at a remote client device. During remoteencryption requests, as described in FIG. 4A, the keyencryption/decryption engine 610 encrypts a received once encryptedencryption key using a remote key encryption key. In one embodiment, thekey encryption/decryption engine 610 can then provide the twiceencrypted encryption key and/or the remote KEK to the key service engineof the cloud-based platform. During remote decryption request, asdescribed in FIG. 4B, the key encryption/decryption engine 610 decryptsa twice encrypted encryption key using a remote key encryption key.

One embodiment of the HSM 600 includes kill circuitry 615 which can beset regardless of the pre-configured rules and reasons. The killcircuitry can include a programmable kill switch that, once set, rejectsthe remote key requests regardless of the pre-configured rules and thereasons. Additionally, the kill circuitry 615 can include functionalityto destroy contents in the event that the system detects tampering withthe HSM 600.

One embodiment of the HSM 600 includes a key store 615 and an audit log620 configured to store keys and log audit information, respectively.

FIG. 7 depicts a data flow diagram 700 illustrating example process 700for facilitating remote key management services in a collaborativecloud-based environment responsive to a content item upload request.Components of a cloud-based platform such as, for example, thecloud-based platform of FIGS. 4A and 4B can, among other functions,perform the example process 700.

To begin, at process 710, the cloud-based platform receives a requestfor upload of a raw file (e.g., content or data item). The request forupload can be received from another machine internal to thecollaborative cloud-based environment, a web application server, anexternal user (collaborator) machine, etc. In one embodiment, a contentinterface such as, for example, the content interface 412 of FIGS. 4Aand 4B can receive the request for upload at the cloud-based platform.At process 712, the cloud-based platform encrypts a raw file using anencryption key. In one embodiment, a content encryption/decryptionengine such as, for example, the encryption/decryption engine 414 ofFIGS. 4A and 4B can encrypt the raw file.

At process 714, the cloud-based platform encrypts the encryption keyusing a local key encryption key (KEK). In one embodiment, a key serviceengine such as, for example, the key service engine 416 of FIGS. 4A and4B can encrypt the encryption key using the local KEK. The key serviceengine can select a local KEK randomly or in any other known manner.

At decision process 716, the cloud-based platform determines if thecontent (upload) request and/or the particular content item isassociated with remote key management functionality. In one embodiment,a key service engine such as, for example, the key service engine 416 ofFIGS. 4A and 4B can make the remote key management determination. Forexample, each data item can be associated with an enterprise and the keyservice engine can identify the enterprise associated with the data itemand determine if the enterprise has key management functionality.Alternatively or additionally, an enterprise or client can handle and/orotherwise manage keys on a case-by-case (or item-by-item) basis. Thatis, the key service engine can determine that the requested data item isassociated with remote key management functionality.

If the content (upload) request and/or the particular content item isnot associated with remote key management functionality then, at process718, the cloud-based platform stores the encrypted content or data itemand associated once encrypted encryption key and local KEK in a datastore. However, if the content (upload) request and/or the particularcontent item is associated with remote key management functionalitythen, at process 720, the cloud-based platform identifies and/orotherwise determines audit log information associated with the request.For example, the audit log information can include metadata associatedwith the content request and a reason code associated with the contentrequest. In one embodiment, a key service engine such as, for example,the key service engine 416 of FIGS. 4A and 4B can identify the metadataassociated with the content request and determine a reason and generatea corresponding reason code as described herein.

In one embodiment, identifying the metadata associated with the contentrequest includes identifying and/or otherwise determining ancillaryinformation associated with the content request. For example, themetadata can include, but is not limited to, an Internet Protocol (IP)address initiating the request, a user identifier (ID) associated withthe request, a file identifier (ID) associated with the request, etc.Other metadata is also possible.

In one embodiment, determining the reason code includes firstidentifying a reason for the content request and subsequently generatinga code associated with the reason. By way of example and not limitation,reasons can include: to fulfill an upload data item request, to fulfilla download or access data item request, to fulfill a maintenancerequest, to perform another action (e.g., to perform a text extractionrequest), to fulfill backend services, etc. Other reasons are alsopossible. Each reason can be coded with reason code.

At process 722, the cloud-based platform generates a remote keyencryption request including at least some of the audit log information.At process 724, the cloud-based platform sends the remote key request toencrypt the encrypted encryption key to a hardware security module. Asdiscussed herein the remote key request can include the encryptedencryption key (also referred to as the once encrypted encryption keyherein), identified or generated metadata associated with the contentrequest, and the generated reason code. A key service engine such as,for example, the key service engine 416 of FIGS. 4A and 4B can initiatethe remote key request.

At a decision process 726, the cloud-based platform may optionally checkif the reason is ok. For example, the cloud-based platform can make thedetermination of whether the reason is acceptable. More specifically, arules processing engine such as, for example, the rules processingengine 535 of FIG. 5 can make this determination. If the reason is notacceptable (i.e., the reason is rejected), then, at process 728, thecloud-based platform receives a rejection and, optionally at process730, notifies the content request requestor (e.g., the system or userinitiating the content request).

At process 732, the cloud-based platform receives a twice encryptedencryption key and a remote KEK and, at process 734, stores theencrypted file with the associated twice encrypted encryption key, thelocal KEK, and the remote KEK. Lastly, at process 736, the cloud-basedplatform optionally provides a confirmation response to the content itemrequestor. In one embodiment, the confirmation could occur at any timesubsequent to the reception of the content request.

FIG. 8 depicts a data flow diagram 800 illustrating example process 800for facilitating remote key management services in a collaborativecloud-based environment responsive to a content item access request.Components of a cloud-based platform such as, for example, thecloud-based platform of FIGS. 4A and 4B can, among other functions,perform the example process 800.

To begin, at process 810, the cloud-based platform receives an accessrequest to download a file (e.g., content or data item). The request foraccess can be received from another machine internal to thecollaborative cloud-based environment, a web application server, anexternal user (collaborator) machine, etc. In one embodiment, a contentinterface such as, for example, the content interface 412 of FIGS. 4Aand 4B can receive the request for upload at the cloud-based platform.

At decision process 812, the cloud-based platform determines if thecontent (access) request and/or the particular content item isassociated with remote key management functionality. In one embodiment,a key service engine such as, for example, the key service engine 416 ofFIGS. 4A and 4B can make the remote key management determination. Forexample, each data item can be associated with an enterprise and the keyservice engine can identify the enterprise associated with the data itemand determine if the enterprise has key management functionality.Alternatively or additionally, an enterprise or client can handle and/orotherwise manage keys on a case-by-case (or item-by-item) basis. Thatis, the key service engine can determine that the requested data item isassociated with remote key management functionality.

If the content (access) request and/or the particular content item isnot associated with remote key management functionality then the processcontinues at process 832 below. However, if the content (access) requestand/or the particular content item is associated with remote keymanagement functionality then, at process 814, the cloud-based platformthe cloud-based platform identifies and/or otherwise determines auditlog information associated with the request. For example, the audit loginformation can include a reason code associated with the contentrequest. In one embodiment, a key service engine such as, for example,the key service engine 416 of FIGS. 4A and 4B can identify the metadataassociated with the content request and determine a reason and generatea corresponding reason code as described herein.

In one embodiment, identifying the metadata associated with the contentrequest includes identifying and/or otherwise determining ancillaryinformation associated with the content request. For example, themetadata can include, but is not limited to, an Internet Protocol (IP)address initiating the request, a user identifier (ID) associated withthe request, a file identifier (ID) associated with the request, etc.Other metadata is also possible.

In one embodiment, determining the reason code includes firstidentifying a reason for the content request and subsequently generatinga code associated with the reason. By way of example and not limitation,reasons can include: to fulfill an upload data item request, to fulfilla download or access data item request, to fulfill a maintenancerequest, to perform another action (e.g., to perform a text extractionrequest), to fulfill backend services, etc. Other reasons are alsopossible. Each reason can be coded with reason code.

At process 818, the cloud-based platform accesses a twice encryptedencryption key, a local KEK, and a remote KEK from a data store. Atprocess 820, the cloud-based platform generates a remote key requestincluding the audit log information to decrypt the encrypted encryptionkey. As discussed herein the audit log information can include the twiceencrypted encryption key, identified or generated metadata associatedwith the content request, the generated reason code, and the remote KEK.A key service engine such as, for example, the key service engine 416 ofFIGS. 4A and 4B can initiate the remote key request. At process 822, thecloud-based platform sends the key decryption request to a hardwaresecurity module (HSM).

At a decision process 824, the cloud-based platform may optionally checkif the reason is ok. For example, the cloud-based platform can make thedetermination if the reason is acceptable. More specifically, a rulesprocessing engine such as, for example, the rules processing engine 535of FIG. t can make this determination. If the remote enterprise clientsystem determines that the reason is not acceptable (i.e., the reason isrejected), then, at process 826, the cloud-based platform receives arejection and, optionally at process 828, notifies the content requestrequestor (e.g., the system or user initiating the content request).

At process 830, the cloud-based platform receives a once encryptedencryption key and, at process 832, accesses the encrypted data itemassociated with the content request from the data store. In variousembodiments, the cloud-based platform can also access a local KEK fromthe data store if the local KEK was not previously accessed at process818.

At process 834, the cloud-based platform decrypts the encrypted dataencryption key using the local KEK.

At process 836, the cloud-based platform decrypts the encrypted dataitem using the unencrypted encryption key. Lastly, the cloud-basedplatform provides the decrypted file content item requestor responsiveto the content request.

FIG. 9 illustrates a diagrammatic representation of a machine in theexample form of a computer system within which a set of instructions,for causing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

In alternative embodiments, the machine operates as a standalone deviceor may be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aclient machine in a client-server network environment, or as a peermachine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personalcomputer (PC), a user device, a tablet PC, a laptop computer, a set-topbox (STB), a personal digital assistant (PDA), a cellular telephone, aniPhone, an iPad, a Blackberry, a processor, a telephone, a webappliance, a network router, switch or bridge, a console, a hand-heldconsole, a (hand-held) gaming device, a music player, any portable,mobile, hand-held device, or any machine capable of executing a set ofinstructions (sequential or otherwise) that specify actions to be takenby that machine.

While the machine-readable medium or machine-readable storage medium isshown in an exemplary embodiment to be a single medium, the term“machine-readable medium” and “machine-readable storage medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” and “machine-readable storage medium” shallalso be taken to include any medium that is capable of storing, encodingor carrying a set of instructions for execution by the machine and thatcause the machine to perform any one or more of the methodologies of thepresently disclosed technique and innovation.

In general, the routines executed to implement the embodiments of thedisclosure, may be implemented as part of an operating system or aspecific application, component, program, object, module or sequence ofinstructions referred to as “computer programs.” The computer programstypically comprise one or more instructions set at various times invarious memory and storage devices in a computer, and that, when readand executed by one or more processing units or processors in acomputer, cause the computer to perform operations to execute elementsinvolving the various aspects of the disclosure.

Moreover, while embodiments have been described in the context of fullyfunctioning computers and computer systems, those skilled in the artwill appreciate that the various embodiments are capable of beingdistributed as a program product in a variety of forms, and that thedisclosure applies equally regardless of the particular type of machineor computer-readable media used to actually effect the distribution.

Further examples of machine-readable storage media, machine-readablemedia, or computer-readable (storage) media include, but are not limitedto, recordable type media such as volatile and non-volatile memorydevices, floppy and other removable disks, hard disks, optical disks(e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks,(DVDs), etc.), among others, and transmission type media such as digitaland analog communication links.

The network interface device enables the machine 700 to mediate data ina network with an entity that is external to the host server, throughany known and/or convenient communications protocol supported by thehost and the external entity. The network interface device can includeone or more of a network adaptor card, a wireless network interfacecard, a router, an access point, a wireless router, a switch, amultilayer switch, a protocol converter, a gateway, a bridge, bridgerouter, a hub, a digital media receiver, and/or a repeater.

The network interface device can include a firewall which can, in someembodiments, govern and/or manage permission to access/proxy data in acomputer network, and track varying levels of trust between differentmachines and/or applications. The firewall can be any number of moduleshaving any combination of hardware and/or software components able toenforce a predetermined set of access rights between a particular set ofmachines and applications, machines and machines, and/or applicationsand applications, for example, to regulate the flow of traffic andresource sharing between these varying entities. The firewall mayadditionally manage and/or have access to an access control list whichdetails permissions including for example, the access and operationrights of an object by an individual, a machine, and/or an application,and the circumstances under which the permission rights stand.

Other network security functions can be performed or included in thefunctions of the firewall, can be, for example, but are not limited to,intrusion-prevention, intrusion detection, next-generation firewall,personal firewall, etc. without deviating from the novel art of thisdisclosure.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof, means any connection or coupling,either direct or indirect, between two or more elements; the coupling ofconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, shall referto this application as a whole and not to any particular portions ofthis application. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above detailed description of embodiments of the disclosure is notintended to be exhaustive or to limit the teachings to the precise formdisclosed above. While specific embodiments of, and examples for, thedisclosure are described above for illustrative purposes, variousequivalent modifications are possible within the scope of thedisclosure, as those skilled in the relevant art will recognize. Forexample, while processes or blocks are presented in a given order,alternative embodiments may perform routines having steps, or employsystems having blocks, in a different order, and some processes orblocks may be deleted, moved, added, subdivided, combined, and/ormodified to provide alternative or subcombinations. Each of theseprocesses or blocks may be implemented in a variety of different ways.Also, while processes or blocks are at times shown as being performed inseries, these processes or blocks may instead be performed in parallel,or may be performed at different times. Further, any specific numbersnoted herein are only examples: alternative implementations may employdiffering values or ranges.

The teachings of the disclosure provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various embodiments described above can be combined toprovide further embodiments.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the disclosure can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further embodiments of thedisclosure.

These and other changes can be made to the disclosure in light of theabove Detailed Description. While the above description describescertain embodiments of the disclosure, and describes the best modecontemplated, no matter how detailed the above appears in text, theteachings can be practiced in many ways. Details of the system may varyconsiderably in its implementation details, while still beingencompassed by the subject matter disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the disclosure should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the disclosure with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the disclosure to the specific embodimentsdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe disclosure encompasses not only the disclosed embodiments, but alsoall equivalent ways of practicing or implementing the disclosure underthe claims.

While certain aspects of the disclosure are presented below in certainclaim forms, the inventors contemplate the various aspects of thedisclosure in any number of claim forms. For example, while only oneaspect of the disclosure is recited as a means-plus-function claim under35 U.S.C. §112, ¶6, other aspects may likewise be embodied as ameans-plus-function claim, or in other forms, such as being embodied ina computer-readable medium. (Any claims intended to be treated under 35U.S.C. §112, ¶6 will begin with the words “means for”.) Accordingly, theapplicant reserves the right to add additional claims after filing theapplication to pursue such additional claim forms for other aspects ofthe disclosure.

1. A method for facilitating remote key management services in acollaborative cloud-based environment, the method comprising: receivinga content request for a data item; determining that the data itemcorresponding to the content request is associated with remote keymanagement functionality; initiating a key request to a hardwaresecurity module (HSM), the key request corresponding to a key that is atleast encrypted twice, wherein an unencrypted key is encrypted a firsttime to produce an encrypted key and the encrypted key while stillencrypted is encrypted a second time to produce the key that isencrypted at least twice, and wherein a secure key response is receivedfrom the HSM with regards to the key that determines whether the dataitem is to be provided in response to the content request; and causingaudit log information associated with the content request to be providedto a log monitoring system, wherein the audit log information includes areason code enumerating a user behavior performed on the data item inthe collaborative cloud-based environment.
 2. The method of claim 1,wherein the HSM stores the audit log information.
 3. The method of claim2, wherein the HSM signs the audit log information with a secure key. 4.The method of claim 1, wherein the audit log information is included inthe key request.
 5. The method of claim 1, wherein the HSM is hosted bythe collaborative cloud-based environment.
 6. The method of claim 1,wherein the HSM is hosted by a second collaborative cloud-basedenvironment distinct from the collaborative cloud-based environment. 7.The method of claim 1, wherein the HSM is hosted by a managed servicesprovider.
 8. The method of claim 1, wherein the HSM provides access tothe collaborative cloud-based environment.
 9. The method of claim 1,wherein the unencrypted key is encrypted with a local key encryption keyby a key service engine and the encrypted key is encrypted with a remoteencryption key by the HSM.
 10. The method of claim 1, wherein thecontent request comprises an access request and wherein the key requestincludes a request to decrypt a twice encrypted encryption key.
 11. Themethod of claim 1, further comprising using the reason code to determinewhether to grant or deny the content request.
 12. A system forfacilitating remote key management services in a collaborativecloud-based environment, the system comprising: one or more processors;a memory unit having instructions stored thereon which, when executed bythe one or more processors, causes the system to: receive a contentrequest for a data item; determine that the data item corresponding tothe content request is associated with remote key managementfunctionality; initiate a key request to a hardware security module(HSM), the key request corresponding to a key that is at least encryptedtwice, wherein an unencrypted key is encrypted a first time to producean encrypted key and the encrypted key while still encrypted isencrypted a second time to produce the key that is encrypted at leasttwice, and wherein a secure key response is received from the HSM withregards to the key that determines whether the data item is to beprovided in response to the content request; and cause audit loginformation associated with the content request to be provided to a logmonitoring system, wherein the audit log information includes a reasoncode enumerating a user behavior performed on the data item in thecollaborative cloud-based environment.
 13. The system of claim 12,wherein the HSM stores the audit log information.
 14. The system ofclaim 13, wherein the HSM signs the audit log information with a securekey.
 15. The system of claim 12, wherein the HSM is hosted by thecollaborative cloud-based environment.
 16. The system of claim 12,wherein the HSM is hosted by a second collaborative cloud-basedenvironment distinct from the collaborative cloud-based environment. 17.The system of claim 12, wherein the HSM is hosted by a managed servicesprovider.
 18. The method of claim 12, wherein the HSM provides access tothe collaborative cloud-based environment.
 19. The system of claim 12,wherein the unencrypted key is encrypted with a local key encryption keyby a key service engine and the encrypted key is encrypted with a remoteencryption key by the HSM.
 20. The system of claim 12, wherein thecontent request comprises an access request and wherein the key requestincludes a request to decrypt a twice encrypted encryption key.
 21. Thesystem of claim 12, wherein the reason code is used to determine whetherto grant or deny the content request.
 22. A computer program productembodied in a non-transitory computer readable medium, the computerreadable medium having stored thereon a sequence of instructions which,when executed by a processor causes the processor to execute a processto facilitate remote key management services in a collaborativecloud-based environment, the method comprising: receiving a contentrequest for a data item; determining that the data item corresponding tothe content request is associated with remote key managementfunctionality; initiating a key request to a hardware security module(HSM), the key request corresponding to a key that is at least encryptedtwice, wherein an unencrypted key is encrypted a first time to producean encrypted key and the encrypted key while still encrypted isencrypted a second time to produce the key that is encrypted at leasttwice, and wherein a secure key response is received from the HSM withregards to the key that determines whether the data item is to beprovided in response to the content request; and causing audit loginformation associated with the content request to be provided to a logmonitoring system, wherein the audit log information includes a reasoncode enumerating a user behavior performed on the data item in thecollaborative cloud-based environment.
 23. The computer program productof claim 22, wherein the HSM stores the audit log information.
 24. Thecomputer program product of claim 23, wherein the HSM signs the auditlog information with a secure key.
 25. The computer program product ofclaim 22, wherein the HSM is hosted by the collaborative cloud-basedenvironment.
 26. The computer program product of claim 22, wherein theHSM is hosted by a second collaborative cloud-based environment distinctfrom the collaborative cloud-based environment.
 27. The computer programproduct of claim 22, wherein the HSM provides access to thecollaborative cloud-based environment.
 28. The computer program productof claim 22, wherein the unencrypted key is encrypted with a local keyencryption key by a key service engine and the encrypted key isencrypted with a remote encryption key by the HSM.
 29. The computerprogram product of claim 22, wherein the content request comprises anaccess request and wherein the key request includes a request to decrypta twice encrypted encryption key.
 30. The computer program product ofclaim 22, wherein the reason code is used to determine whether to grantor deny the content request.